home *** CD-ROM | disk | FTP | other *** search
- From: bousch@topo.matups.fr (Thierry Bousch)
- Subject: Re: sending signals from xdd's
- Date: Wed, 20 Apr 1994 01:01:09 +0200 (MET DST)
- In-Reply-To: <9404181313.AA15886@hera.rbi.informatik.uni-frankfurt.de> from "Kay Roemer" at Apr 18, 94 03:13:28 pm
-
- Hello Kai,
-
- > Usually Unixes do this by
- > 1) sending this sockets owner a SIGURG signal and
- > 2) waking up any processes seleting for exceptional conditions
- > on this socket.
- >
- > The 1st would require a device driver to be able to send signals
- > to ANY process, even if the current process' effective UID is
- > not zero and different from the effective UID of the process that
- > should be signaled.
-
- This is very analogous to a serial driver, which must send a SIGHUP signal to
- the process group controlled by this device.
-
- > Currently the only possibility I see to do the 1st is to fork a
- > new process (much like minixfs and modm0dev do) that is used to
- > send signals.
-
- It seems mandatory, indeed: if no process does I/O on the socket, the
- device driver functions will never be called, so you can't rely on these
- functions to post signals. Signals should be posted asynchronously, by
- another thread.
-
- > Is there another way (without a different process) to signal
- > different processes from a device driver?
- >
- > Perhaps (as Juergen suggested some time ago) post_sig() should be
- > made available for device drivers through struct kerinfo?
-
- While it would be a Good Thing, it would not solve the problem indicated
- before, i.e. you still need another thread. But it would have the great
- advantage of allowing this thread to execute in kernel mode, so
- addroottimeout() would be usable...
-
- Thierry.
-
-